home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re Content⁄Frame⁄Part question < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  1.9 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Content/Frame/Part question
  2. Sent:        5/20/96 6:55 PM
  3. Received:    5/22/96 8:32 AM
  4. From:        Serge Froment, sfroment@odyssee.net
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >Is that the right idiom for "just in time" content updating, where it would
  9. >be too expensive and unnecessary for a frame to adjust the content with
  10. >each change the user makes? Or have I overlooked something you put in ODF
  11. >for R1?
  12.  
  13. There are several way this can be done. Here is how I do it in my parts:
  14.  
  15. - My view have an associated view-content class, which is a mixin that
  16. inherits FW_MNotifier and post notification anytime the content is
  17. modified.
  18.  
  19. - My view inherit FW_MReceiver, display the associated view-content class,
  20. and register to notifications posted by this class in the CreateSubViews
  21. method.
  22.  
  23. - My FW_CContent class inherit one or several view-content classes.
  24.  
  25. - On DoMouseDown or other appropriate places, my view creates a FW_CCommand
  26. object that track the change and directly modify the view-content class.
  27.  
  28. - The view-content class then post notification so all views displaying the
  29. data can synchronize to the changes.
  30.  
  31. The benefits of this approach is that there is very few dependencies in the
  32. code:
  33.  
  34. - Only the view knows about the view-content data being displayed.
  35. - The frame knows nothing about the view and the view-content data except
  36. when it creates the subviews.
  37. - The part knows nothing about the view-content data except in
  38. internalize/externalize, where it merely calls
  39. MViewContent::Internalize/Externalize.
  40. - I don't need to iterate through all frames to make sure the "view in
  41. window" is synchronized.
  42. - The view class as well as the view-content class can be reused in several
  43. OpenDoc parts.
  44. - If the same data is displayed at more places, I don't have to update
  45. existing code. All those new views will be synchronized as well.
  46.  
  47. Serge
  48.  
  49.